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COMP UTING APPARATUS AND METHODS OF OPERATING COMPUTING APPARATUS 

~ ~~ (HP Ref: 3039056) 

Technical Field 

This invention relates to computing apparatus and particularly, but not exclusively, to 
5 computing apparatus and methods of operating computing apparatus in a secure 
environment using security tokens. 




Background Art 

Security tokens, for example • smart cards or cryptographic co-processors, have 
1 0 recently been proposed for various security functions including accessing computer platforms 
(or 'host platforms') and electronic commerce. For instance, a smart card storing confidential 
information accessible only to a related user can be used by the user to log on to a 
computer, to sign a document, or to provide credentials needed for electronic commerce- 
In some cases, it is expected that more than one security token for plural different 
15 applications may need to be used in a single communication session, which starts as the 
user logs on to a host platform and finishes as the user logs off. 

One possible model works as follows. A user has a number of tokens and, in each 
session, they use one of these tokens (for example, a logon token) for authentication to a 
host platform in the logon process only. During the same session, the user separately uses 
20 other tokens (for example, auxiliary tokens) for other security functions, such as electronic 
payment or cryptography. 

Disclosure of the Invention 

In arriving at the present invention, the present inventors have appreciated the 

25 following three potential problems with this model: 

Problem A - there is an inherent danger of a user walking away after logging on to the 
host platform, thus allowing an impostor to use the platform. 

Problem B - a fake host platform may be able to steal sensitive information from the 

30 user. 

Problem C - there are some auxiliary tokens whose owner's identities are not 
traceable to the owner of the logon token. In other words, an impostor, who does not own 
the logon token, may be able to use his own auxiliary tokens to impersonate the logon 
token's owner. 

35 In addressing one or more of the above problems, the present inventors propose a 

new arrangement to reduce security risk and to establish a more trusted relationship 
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between a host platform and one or more security tokens. Typically, the arrangement 
implements a security control policy that is more refined than the policy in the prior art model, 
including periodic or repeated authentication. Preferred embodiments of the inu^ion 
implement mutual authentication and privilege restriction. In particular, ^^H ed 
5 embodiments utilise a novel method of binding the identity of a logon, or primary .^^Jrity 
token with one or more auxiliary tokens. Of utmost importance is that the invention meets 
the important criteria of being easy to use at relatively cheap to implement compared with 
prior art solutions. 

In accordance with a first aspect, the present invention provides computing apparatus 
10 comprising: 

memory means storing the instructions of a secure process and an 
authentication process; 

processing means arranged to control the operation of the computing 
apparatus including by executing the secure process and the authentication process as 
15 required; 

user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user input; and 

interface means for receiving a removable primary token and communicating 
with the token, the token comprising a body supporting: 
20 a token interface for communicating with the interface means; 

a token processor; and 

token memory storing token data including information for identifying the 

token. 

wherein the processing means is arranged to receive the identity information 
25 from the primary token, authenticate the token using the authentication process and, if the 
token is successfully authenticated, permit a user to interact with the secure process via th^| 
user interface means, 

and wherein the processing means is arranged to repeatedly authenticate the primary 
token and cause the computing platform to suspend interaction between the secure process 
30 and the user if authentication is not possible as a result of the removal of the primary token. 

In accordance with a second aspect, the present invention provides a method of 
controlling computing apparatus to authenticate a user, comprising the steps: 

the computing apparatus receiving a primary token of the user, the primary token 
containing information suitable for authenticating the primary token; 
35 jf the token is authentic, permitting the user to interact with one or more secure 

applications that may be executed by the computing platform; 
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at intervals, re-authenticating the primary token; and 

if it is not possible to re-authenticate the primary token, suspending the interaction 
between the computing apparatus and the user. 

Other aspects of the - invention will become apparent from the accompanying 
5 description, claims and drawings. 

Brief Description of the Drawings - to be updated 

Preferred embodiments of the present invention will now be described, by way of 
example only, with reference to the accompanying drawings, of which: 



10 



Figure 1 is a diagram which illustrates a system capable of implementing 
embodiments of the present invention; 

Figure 2 is a diagram which illustrates a motherboard including a trusted device 
arranged to communicate with a number of smart cards via a single smart card reader; 
15 Figure 3, is a diagram that illustrates the trusted device in more detail; 

Figure 4 is a diagram that illustrates the operational parts of a logon smart card 
according to the present invention; 

Figure 5 is a flow diagram which illustrates the process of mutually authenticating a 

logon smart card and a host platform; 
20 Figure 6 is a flow diagram which illustrates one general example of introducing an 

auxiliary smart card to a host platform using by a logon smart card; 

Figure 7 is a flow diagram which illustrates one example of the operation between an 
introduced cash card and the host platform; 

Figure 8 is a flow diagram which illustrates one example of a single session 

25 temporary delegation mode; and 

Figure 9 is a flow diagram which illustrates one example of a multiple session 

temporary delegation mode. 

Best Mode For Carrying Out the Invention. & Industri al Applicability 

30 While the ideas of the invention are general, for ease of discussion, we will focus on 

preferred embodiments, wherein smart cards are the security tokens, which interact with a 
trusted computing platform, or simply "platform". In particular, a user has one logon smart 
card and a number of auxiliary smart cards, and needs to interact with the platform, wh.ch 
has only a single smart card reader. It is assumed In the present embodiment that there is 

35 no way for more than one smart card to be read by the smart card reader at the same time. 
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In order to address Problem A, as highlighted in the "Description of Prior Art", the 
present embodiments implement a coherent security control policy using a logon smart card 
operating with the platform. Specifically, to limit the potential for an impostor gettinga^^s 
to the trusted platform without the legitimate user's knowledge,- the logon smart card ^Ho 
5 be present throughout the session, rather than just to initiate the session. By analog?^ 16 
logon smart card is used more like a car key than a door key. 

In effect, a user is held responsible for their actions. Since the smart card has to be 
present during the execution of a command, this effectively and unambiguously holds the 
owner of the smart card responsible for the action. As will be described below, the 
1 0 authentication is done automatically by the platform and does not generally require actions 
from the user. This amounts to a saving of time for the user and is. thus, a very attractive 
feature. 

A major strength of the proposed scheme lies in its intuitive appeal. People are ™ 
familiar with the importance of protecting their keys and accept full responsibility for 

15 respective misuse of the keys! The present scheme, which greatly enhances security, is 
simple to implement. As an added security feature, it is preferable that the logon smart card 
is also password protected, requiring a user to enter a password when the card is first 
inserted into the smart card reader. Password techniques are well-known and will not be 
described herein, so as not to obscure the Invention. 

20 Generally, to check the presence of the logon smart card, the platform needs 

repeatedly to authenticate the logon card. The actual frequency of the authentication can be 
configured by either a system administrator or the user. In practice, one would set the 
frequency high enough that the user, or an unauthorised user, would be unable to subvert 
the platform and carry out an unauthorised transaction between authentications. For 

25 example, authentication may occur every few seconds. 

A further security feature that can be implemented in the security policy is a time-limit 
for each authenticated session using an auxiliary smart card. The user interface may also be 
locked unless a new round of authentication is performed within the pre-set timeMimit 
Further, preferably, time-stamping, or the use of nonces, is used to prevent "replay attacks" 

30 during authentication. 

To address the fake host platform problem, Problem & above, the preferred 
embodiments use the concept of a trusted device built into the platform, which allows a user 
to verify the integrity of the platform. The concept of such a trusted device is the subject of 
the applicant's co-pending European patent application entitled "Trusted Computing 

35 Platform" filed on 15 February 1999, the entire contents of which are hereby incorporated 
herein by reference. 
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To address Probl m C, as highlighted in the "Description of Prior Art", where an 
auxiliary smart card may not be traceable to the owner of the logon smart card, the present 
embodiments introduce the concept of a user profile that binds a user to a number of 
auxiliary smart cards. This makes the implementation of a coherent, comprehensive and 
flexible security control policy extremely simple, inexpensive and transparent to the user. 

Generally, in the preferred embodiments, it is always assumed that logging on is 
done by a logon smart card, and at some point of the session, the user (or the application 
running under the session) needs to use one or more auxiliary smart cards, so that removal 
of the logon card becomes necessary. To maintain the security policy of repeated 
10 authentication, there needs to be a security chain for the platform between trusting the logon 
smart card and trusting other auxiliary smart cards. This chain is built by letting the logon 
smart card 'introduce' the auxiliary cards to the platform, for example by using 'user profiles'. 

For the sake of simplicity of description, only two types of auxiliary smart cards are 

considered in any detail herein: 
15 -Cash cards", which are smart cards having cash values (or credits) that are 

transferable; and 

-Crypto cards", which are smart cards whose privileges (such as encryption or 
signature supported by a private key) are not transferable. 

A trusted platform 10 incorporating a smart card reader 12 is illustrated in the diagram 
20 in Figure 1. The platform 10 includes the standard features of a keyboard 14. mouse 16 and 
visual display unit (VDU) 18, which provide the physical 'user interface' of the platform. 
Along side the smart card reader 12, there are illustrated a logon smart card 19 and plural 

auxiliary smart cards 20. 

Conveniently, the present invention uses the platform that is described in detail in the 

25 present applicant's co-pending patent application referred to above. White this platform is 
ideal for the purposes of the present embodiment, and allows a user to verify the integrity of 
the platform, use of the platform is by no means essential to the present invention. In 
particular, the present invention does not necessarily require a user to verify the integrity of 
the platform, which might be acceptable, for example, if the platform is a private platform in a 

30 users own home. The main advantage of using a platform having a trusted device is realised 
in an environment where many users potentially have access to the platform, thereby 
providing reasonable opportunity for the platform to be subverted in some way. The ma.n 
features of a platform including a trusted device will now be reproduced herein purely for the 
reader's convenience. 

35 AS illustrated in Figure 2. the motherboard 20 of the trusted computing platform 10 

(as described in the applicant's co-pending application) includes (among other standard 
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components) a main processor 21 , main memory 22. a trusted device 24, a data bus 26 and 
respective control lines 27 and address lines 28 t BIOS memory 29 containing the BIOS 
program for the platform 10 and an Input/Output (IO) device 23, which controls intec^ticm 
between the components of the motherboard and the smart card reader 12, the keyb^^Bl, 
5 the mouse 16 and the VDU 18. The main memory 22 is typically random access n^Wbry 
(RAM). In operation, the platform 10 loads the operating system, for example Windows 
NT™, into RAM from hard disk (not shown). Additionally, in operation, the platform 10 loads 
the processes or applications that may be executed by the platform 1 0 into RAM from hard 
disk (not shown), in the present case, the key applications are an authentication application 

1 0 and a secure application, the operations of which will be described below. 

Typically, for a conventional IBM-compatible platform (i.e. a "PC"), the BIOS program 
Is located in a special reserved memory area, the upper 64K of the first megabyte do the 
system memory (addresses F000h to FFFFh), and the main processor is arranged to look 0 
at this memory location first, in accordance with an industry wide BIOS standard. 

15 A significant difference between the present trusted platform 10 and a conventional 

platform is that, after reset, the main processor 21 is initially controlled by the trusted device 
24, which then hands control over to the platform-specific BIOS program, which in turn 
initialises ail input/output devices as normal. After the BIOS program has executed, control 
is handed over as normal by the BIOS program to the operating system. 

20 The trusted device 24 comprises a number of blocks, as illustrated in Figure 3. After 

system reset, the trusted device 24 performs a secure boot process to ensure that the 
operating system of the platform 10 (including the system clock and the display on the 
monitor) is running properly and in a secure manner. During the secure boot process, the 
trusted device 24 acquires an integrity metric of the computing platform 10. The trusted 

25 device 24 can also perform secure data transfer and, for example, authentication between it 
and a smart card via encryption/decryption and signature/verification. The trusted device 24 
can also securely enforce various security control policies to be discussed below including 
frequent authentication and the locking of user interface. 

Specifically, the trusted device 24 comprises: a controller 30 programmed to control 

30 the overall operation of the trusted device 24. and interact with the other functions on the 
trusted device 24 and with the other devices on the motherboard 10; a measurement function 
31 for acquiring the integrity metric from the platform 10: a cryptographic function 32 for 
signing^ encrypting or decrypting specified data; an authentication function 33 for 
authenticating a logon smart card 19; and interface circuitry 34 having appropriate ports (36, 

35 37 & 38) for connecting the trusted device 24 respectively to the data bus 26, control lines 27 
and address lines 28 of the motherboard 10. Each of the blocks in the trusted device 24 has 
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access (typically via the controller 20) to appropriate volatile memory areas 37 and/or non- 
volatile memory areas 38 of the trusted device 24. Additionally, the trusted device 24 is 
designed, in a known manner, to be tamper resistant. 

For reasons of performance, the trusted device 24 may be implemented as an 
application specific integrated circuit (ASIC). However, for flexibility, the trusted device 24 is 
preferably an appropriately programmed micro-controller. Both ASICs and micro-controllers 
are well known in the art of microelectronics and will not be considered herein in any further 
detail. 

One item of data stored in the non-volatile memory of the trusted device 24 is a 
10 certificate 350. The certificate 350 contains at least a public key 351 of the trusted device 24 
and an authenticated value 352 of the platform integrity metric measured by a trusted party 
(TP). The certificate 350 is signed by the TP using the TP's private key prior to it being 
stored in the trusted device 24. In later communications sessions, a user of the platform 10 
can verify the integrity of the platform 10 by comparing an acquired integrity metric with the 
15 authentic integrity metric 352. If there is a match, the user can be confident that the platform 
10 has not been subverted. Knowledge of the TP's generally-available public key enables 
simple verification of the certificate 350. The non-volatile memory 35 also contains an 
identity (ID) label 353. The ID label 353 is a conventional ID label, for example a serial 
number, that is unique within some context. The ID label 353 is generally used for indexing 
20 and labelling of data relevant to the trusted device 24, but is insufficient in itself to prove the 
identity of the platform 10 under trusted conditions. 

The trusted device 24 is equipped with at least one method of reliably measuring or 
acquiring the integrity metric of the computing platform 10 with which it is associated. In the 
present embodiment, the integrity metric is acquired by the measurement function 31 by 
25 generating a digest of the BIOS instructions in the BIOS memory. Such an acquired integrity 
metric, if verified as described above, gives a potential user of the platform 10 a high level of 
confidence that the platform 10 has not been subverted at a hardware, or BIOS program, 
level. Other known processes, for example virus checkers, will typically be in place to check 
that the operating system and application program code has not been subverted. 
30 The measurement function 31 has access to: non-volatile memory 35 for storing a 

hash program 354 and a private key 355 of the trusted device 24: and volatile memory 42 for 
storing the public keys and associated ID labels 360a-360n of one or more authentic logon 
smart card 19s that can be used to gain access to the platform 10, and an acquired integrity 

metric in the form of a digest 361 . 
35 A processing part 40 of a logon smart card 1 9 is illustrated in Figure 4. As shown, the 

logon smart card 19 40 has the standard features of a processor 41. memory 42 and 
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interface contacts 43. The processor 41 is programmed for simple challenge/response 
operations involving authentication of the logon smart card 19 and verification of the platform 
10, as will be described below. The memory 42 contains its private key 420 t its pu^^ey 
428, a user profile 421 , the public key 422 of the TP and an identity 427. The us^Be 
5 421 lists the allowable auxiliary smart cards 20 AC1-ACn usable by the user, a'r^TOie 
individual security policy 424 for the user. For each auxiliary smart card 20, the user profile 
includes respective identification information 423, the trust structure 425 between the smart 
cards (if one exists) and, optionally, the type or make 426 of the smart card. 

In the user profile 421. each auxiliary smart card 20 entry AC1-ACn includes 
10 associated identification information 423, which varies in dependence upon the type of card. 
For example, identification information for a cash card typically includes a simple serial 
number, whereas, for a crypto card, the Identification information typically comprises the 
public key (or certificate) of the crypto card (the private key being stored secretly on the £ 
crypto card itself). 

15 The 'security policy' 424 dictates the permissions that the user has on the platform 10 

while using an auxiiiary smart card 20. For example, the user interface may be locked or 
unlocked while an auxiliary smart card 20 is in use, depending on the function of the auxiliary 
smart card 20. Additionally, or alternatively, certain files or executable programs on the 
platform 10 may be made accessible or not. depending on how trusted a particular auxiliary 

20 smart card 20 is. Further, the security policy 424 may specify a particular mode of operation 
for the auxiliary smart card 20, such as 'credit receipt' or 'temporary delegation', as will be 
described below. 

A 'trust structure" 425 defines whether an auxiliary smart card 20 can itself 'introduce' 
further auxiliary smart cards 20 into the system without first re-using the logon smart card 19. 

25 in the embodiments described in detail herein, the only defined trust structure is between the 
logon smart card 19 and the auxiliary smart cards 20 that can be introduced to the platforrr^ 
10 by the logon smart card 19. Introduction may be 'single session' or 'multi-session 1 , as will 
be described below. However, there is no reason why certain auxiiiary smart cards 20 could 
not in practice introduce further auxiliary smart cards 20. Tfiis would require an auxiliary 

30 smart card 20 to have an equivalent of a user profile listing the or each auxiliary smart card 
that it is able to introduce. 

A preferred process for authentication between a logon smart card 19 and a platform 
10 will now be described with reference to the flow diagram in Figure 5. As will be described, 
the process conveniently implements a challenge/response routine. There exist many 

35 available challenge/response mechanisms. The implementation of an authentication 
protocol used in the present embodiment is mutual (or 3-step) authentication, as described in 
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ISO/1EC 9798-3 [1]. Of course, there is no reason why other authentication procedures 
cannot be used, for example 2-step or 4-step. as also described in [1]. 

initially, the user inserts their logon smart card 19 into the smart card reader 12 of the 
platform 10 in step 500. Beforehand, the platform 10 will typically be operating under the 
5 control of its standard operating system and executing the authentication process, which 
waits for a user to insert their logon smart card 19. Apart from the smart card reader 12 
being active in this way, the platform 10 is typically rendered inaccessible to users by 
•locking 1 the user interface (i.e. the screen, keyboard and mouse). 

When the logon smart card 19 is inserted into the smart card reader 12. the trusted 
10 device 24 is triggered to attempt mutual authentication in step by generating and transmitting 
a nonce A to the logon smart card 19 in step 505. A nonce, such as a random number, is 
used to protect the originator from deception caused by replay of old but genuine responses 
(called a replay attack - ) by untrustworthy third parties. 

In response, in step 510. the logon smart card 19 generates and returns a response 
15 comprising the concatenation of: the plain text of the nonce A, a new nonce B generated by 
the logon smart card 19, the ID 353 of the trusted device 24 and some redundancy: the 
signature of the plain text, generated by signing the plain text with the private key of tne 
logon smart card 19; and a certificate containing the ID and the public key of the logon smart 
card 19. 

20 The trusted device 24 authenticates the response by using the public key in the 

certificate to verify the signature of the plain text in step 515. If the response is not authentic, 
the process ends in step 520. If the response is authentic, in step 525 the trusted device 24 
generates and sends a further response including the concatenation of: the ptam text of the 
nonce A. the nonce B. the ID 427 of the logon smart card 19 and the acquired integnry 

25 metric- the signature of the plain text, generated by signing the plain text using the pnvate 
key of the trusted device 24; and the certificate comprising the public key of the trusted 
device 24 and the authentic integrity metric, both signed by the private key of the TP. 

The logon smart card 19 authenticates this response by using the public key of the 
TP and comparing the acquired integrity metric with the authentic integrity metric, where a 

30 match indicates successful verification, in step 530. If the further response is not authentic, 

the process ends in step 535. 

,f the procedure is successful, both the trusted device 24 has authenticated, the logon 
smart card 19 and the logon smart card 19 has verified the integrity of the trusted platform 10 
and in step 540, the authentication process executes the secure process for the user. Then, 
35 the authentication process sets an interval timer in step 545. Thereafter, using appropnate 
operating system interrupt routines, the authentication process services the interval timer 
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periodically to detect when the timer meets or exceeds a pre-determined timeout period in 
step 550. 

Clearly, the authentication process and the interval timer run in parallel^^^the 
secure process. ^^^r 
5 When the timeout period is met or exceeded, the authentication process triggers the 

trusted device 24 to re-authenticate the logon smart card 1 9, by transmitting a challenge for 
the logon smart to identify itself in step 560. The logon smart card 19 returns a certificate 
including its ID 427 and its public key 428 step 565. In step 570. if there is no response (for 
example, as a result of the logon smart card 19 having been removed) or the certificate is no 
10 longer valid for some reason (for example, the logon smart card has been replaced with a 
different smart card), the session is terminated by the trusted device 24 in step 575. 
Otherwise, in step 570, the process from step 545 repeats by resetting the interval timer. £ 

A preferred, general process for introducing an auxiliary smart card 20 into a platform 
10 will now be described with reference to the flow diagram in Figure 6. 
15 When the secure process running on the platform 10 reaches a point where the logon 

smart card 1 9 needs to be replaced by an auxiliary smart card 20, for example at the time a 
cash card is needed to credit the platform 1 0 with funds for a remote transaction, in step 605 
the secure process retrieves tne user profile from the trusted device 24 and stores it in its 
volatile memory 35. The trusted device 24 then extracts the details of the auxiliary smart 
20 cards (AC) 20 from the user profile and returns the details to the secure process in step 610. 
In step 615, the secure process displays an option list of auxiliary smart cards 20 and asks 
the user to select one. The secure process receives the users selection in step 620 and 
displays a message asking the user to replace the logon smart card 19 with the (or one of 
the) selected auxiliary smart card(s) 20 in step 625. As soon as the user ejects the logoij^ 
25 smart card 19, the trusted device locks the user interface in step 630 and, in step 635, the 
secure process initialises the authentication process interval timer with a new timeout period, 
which determines the allowable duration of the auxiliary smart card session. 

[In parallel with the operation of the secure process, which has been described with 
reference to Figure 5). if the timeout period expires before the logon smart card 19 has been 
30 reinstated, the authentication process suspends the session (i.e. the secure process) and 
provides the user with an appropriate message. The authentication process has the 
authority to suspend the secure process, since it executed the secure process in the first 
instance. Clearly, the new timeout period needs to be sufficient for the required purposes, 
and may be configurable by a system administrator for this reason.} 
35 When the user inserts the selected auxiliary smart card 20, the trusted device 24 is 

triggered to send the auxiliary smart card 20 a challenge to identify itself in step 640. The 




15-03-98 19:42 44 117 922 8941 r-io <™« 

/03 *99 19:47 FAX 44 117 922 8941 HP UK IP SECTION ©016 



11 

auxiliary smart card 20 responds by returning its identity information to th trusted device 24 
in step 645. The trusted device 24 then verifies the identity information by comparing it with 
the stored user profile information in step 650. 

lf the trusted device 24 is unable to verify the auxiliary smart card 20 for any reason. 
5 in step 655 the session ends and the secure process displays an appropriate message for 
the user. Otherwise, in steps 660 and 665, the secure process interacts with the auxiliary 

smart card 20 as required. 

When the interaction is complete, in step 670, the secure process displays a prompt 

to the user to replace the auxiliary smart card 20 with the logon smart card 19. When the 
10 user ejects the auxiliary smart card 20 form the smart card reader 12 and inserts the logon 

smart card 19. the trusted device 24 is triggered to authenticate the logon smart card 19. by 

executing from step 560 in Figure 5, as described above, resulting in the session ending in 

step 575 or continuing in step 545. 

Additionally, or alternatively, in some embodiments it may be required that the user 
15 profile- is encrypted and signed to protect privacy and integrity. If so. a secure data transf r 

protocol may be needed between the trusted device 24 and the logon smart card 19. There 

exist many available mechanisms for transferring secure credentials between two entities. A 

possible implementation, which may be used in the present embodiment is secure key 

transport mechanisms from ISO/IEC DIS 11770-3 [2]. 
20 Clearly, the operation of the process that has just been described for introducing an 

auxiliary smart card 20 may vary in dependence upon the type of the auxiliary smart card 20; 

for example, whether it is a cash card or a crypto card. Variations in process for different 

types of auxiliary smart card 20 will now be described. 

25 CREDIT RECEIPT MODE 

A credit receipt mode allows a user to remove the logon smart card 19 for a very brief 
period of time (say 2 minutes, which is configurable by a system administrator or a user) from 
the smart card reader 12 to allow credits (or cash values) from a cash card to be transferred 
to the trusted device 24 of the platform 10 without undue security risk. 

30 Figure 7 illustrates the process for enacting credit receipt mode. The steps that 

correspond to those illustrated in Figure 6 will not be specifically described again. 

It is assumed that a user profile that lists auxiliary smart cards 20 including cash 
cards is stored in the logon smart card 19. As before, when a user invokes an application 
that requires cash values, the secure process displays a request for the user to choose a 

35 cash card from those listed in the user profile. 
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The first difference between the credit receipt mode process and the process in 
Figure 6 is that in step 721 the secure process displays a further request for the user to enter 
the amount of the credit transfer. The secure process receives the entered amouni^fctep 
722 and forwards a respective value to the trusted device 24 in step 723. The trust^^^^e 
5 24 transfers the credits from the cash card to the trusted device 24 in steps 760 and 765, 
after the cash card has been inserted and authenticated. 

As an alternative or additional feature, depending on the security policy, unauthorised 
cash cards may also be used; for example, there may be an option "Others" in the list of 
authorised cash cards. Clearly, the risks associated with receiving credits from any auxiliary 

1 0 smart card 20 are relatively low. 

Typically, only a relatively short time is required to enact the whole process of 
transferring the credits. The length of the timeout period is determined by the security policy 
in the user profile. If the timeout is exceeded, the transfer process is aborted and the user 
interface is temporarily locked. On the other hand, if the user reinserts the logon smart card 

15 19 within the specified time-limit, a new round of authentication is performed between the 
smart card and the platform 10. Upon successful verification, the user interface will be 
unlocked and the original session, i.e. before the credit transfer mode, resumes, but with the 
cash value now stored in the trusted device 24. The cash value may be used for, for 
example, electronic commerce. 

20 Since the user interface is essentially locked during the credit transfer mode, and is 

re-activated only after the re-insertion of the logon smart card 19, the host platform 10 does 
not suffer any serious security risk in the credit receipt mode. Further, since the user has to 
authenticate which cash card to use, using the logon smart card 19. abuse of cash cards by 
illegal users is also minimised. 

25 

TEMPORARY DELEGATION MODES 

It will be appreciated that for a crypto card to function (say for encryption, decryption, 
signature and verification), it potentially needs to be inserted in the place of a logon card for a 
substantial amount of time, unlike for cash cards. To address the need for potentially greater 

30 periods of time to use a crypto card, the present embodiment includes what is referred to as 
a temporary delegation mode, which allows a user to use crypto cards in place of the logon 
card for an undefined time, subject to possible respective security policy limitations. 
Temporary delegation modes will now be described with reference to the flow diagram in 
Figure 8. The steps that correspond to those illustrated in Figure 6 will not be specifically 

35 described again. 
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To invoke a temporary delegation mode, a user (or the secure process) selects a 
temporary delegation mode in step 800 while the logon smart card 19 is being used. In 
response, the host platform 10 takes the steps to receive and authenticate the auxiliary smart 
card 20, which in this example is a crypto card. 
5 When provided with a list of allowable crypto cards, the user specifies the authorised 

crypto card. Depending on the security policy, unregistered crypto cards may or may not be 
used. Again, if the user profile is encrypted, a secure data transfer protocol (again, see [2]) 
may be employed. 

After the logon smart card 19 is removed, the user interface is locked and a the 
10 secure process displays a message requesting a new smart card. 

Upon insertion and authentication of the specified crypto card, the secure process 
activates user privileges in step 833 consistent with the security policy of the crypto card. 
For example, the user may need to use the user interface for entry of certain information 
related to the crypto card operation, but should not be able to execute any other process or 
1 5 perform any other operation. 

When the crypto card is removed from the smart card reader 12, the user interface is 
locked again, until the logon smart card 19 is inserted and authenticated. 

The example of the temporary delegation mode described above allows a single 
auxiliary smart card 20 to be used in a 'single session* in place of the logon smart card 1 9 for 
20 an undefined period of time. 

An alternative, or additional, temporary delegation mode permits multiple auxiliary 
smart cards 20 to be used In turn, in place of the logon smart card 19, without the need to re- 
insert the logon smart card 19. An example of such a 'multi-session* temporary delegation 
mode will now be described with reference to Figure 9. As before, the steps that correspond 
25 to those illustrated in Figure 6 will not be specifically described again. 

In a multi-session, multiple auxiliary smart cards 20 can be freely used in place of the 
logon smart card 19, thus allowing maximal convenience of use. 

To invoke a multi-session temporary delegation mode, a user (or the secure process) 
selects a multi-session temporary delegation mode in step 900 while the logon smart card 19 
30 is being used. 

A significant difference between a multi-session temporary delegation mode and the 
single session temporary delegation mode is that, when provided with the list of available 
authorised auxiliary smart cards 20 in step 915, the user can select multiple authorised 
auxiliary smart cards 20 in step 920. The selected auxiliary smart cards 20 may be of 
35 different kinds depending on the user's requirements. 
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The host platform 10 takes the steps to receive and authenticate any one of the 
selected auxiliary smart cards 207 

As soon as the logon smart card 19 is ejected the user interface is locked, th|^^tore 
process activates user privileges consistent with the operation of that auxiliary smar^^^^O 
5 in step 933. When the auxiliary smart card 20 is eventually ejected, the process loops to 
step 925, a message is generated to replace the card and the user interface is locked again 
in step 930. When the next auxiliary smart card 20 is inserted, the secure process activates 
user privileges consistent with the operation of that auxiliary smart card 20 in step 933 again. 
This procedure may be repeated for any of the selected auxiliary smart cards 20 until 

10 the session ends or the logon smart card is re-inserted in step 975. In other words, the user 
can use any combination of the selected auxiliary smart cards 20 without the need of the 
insertion of the logon smart card 19 during the whole multi-session. Clearly, such a| 
permissive multi-session is very convenient for the user, although the benefits need to be 
weighed against the risks of such freedom. 

15 Note that a security control policy described in the user profile may give constraints 

on the number, types and makes of smart cards allowed in a multi-session as well as any 
time-limits. Typically, different auxiliary smart cards 20 give the user different sets of 
privileges. For instance, some sensitive files may be locked whenever the auxiliary smart 
card 20 currently being used is regarded to be not trustworthy enough. Indeed, any truly 

20 sensitive application may require the insertion of the logon smart card 19 again for 
authentication. 

Since it is not easy to estimate how long a temporary delegation mode will last, in 
theory, it might be acceptable to have no timeout period as such, as in the examples above. 
However, there are risks associated with such a policy, for example a user may leave the - 

25 platform 10 during a temporary delegation mode session. Therefore, it is preferable to have 
an overall timeout period, fixed for the temporary delegation mode session, which overrides 
both the normal re-authentication timeout period of the authentication process and the 
individual timeout periods associated each auxiliary smart card 20. Additionally, it might also 
be possible to have individual timeout periods for certain auxiliary smart cards 20. As usual, 

30 the specification of the timeout period(s) will be determined by the security policies for the 
auxiliary smart cards 20. In practice, the timeout period for a temporary delegation mode is 
implemented by the secure process overriding the authentication process. Exemplary fixed 
session timeout periods for temporary delegation modes are 30 minutes. 1 hour or 2 hours. 
The period(s) can be set or modified by the user or a system administrator, and may depend 

35 on the trustworthiness of the platform 1 0. 
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Re-insertion of the original logon card will typically be needed for- extending the 
temporary delegation mode session, and. generally, the secure process issues a warning 
message to the user prior to expiration. This is analogous to request for insertion of coins in 
a phone booth during phone calls. Upon expiration, the user interface will be locked and can 
5 be unlocked only by the logon card. If a user attempts to use a time-consuming applicat.on 
in a temporary delegation mode, the secure process may request the insertion of a logon 
smart card 19 beforehand to avoid locking the user interface in the middle of an application. 

There are a variety of possible, different temporary delegation modes that generally 
specify the class of auxiliary smart cards 20 and applications allowed during the temporary 
10 delegation mode. For instance, in some modes, perhaps only a single type of auxiliary smart 
card 20 (possibly with traceable ID) is allowed. In other modes, only a small class of 
auxiliary smart cards 20 is allowed. In yet other modes, a large class of auxiliary smart cards 
20 is allowed. 

The exact set of pnVUeges that can be delegated is a function of the system security 
15 policy a choice by the user (in set-up and/or during the session itself), and the type and 
make'of the auxiliary card being used. Some privileges may be revoked during a temporary 
delegation mode. For instance, some files (currently on screen or otherwise) may become 
locked once the temporary delegation mode is employed. High security applications m.ght 
request the re-insertion of the original logon card, in an extreme case, all privileges except 
20 for the specific application may be temporarily suspended during the temporary delegation 
mode. 

As an alternative, or in addition, to the embodiments described above, the logon 
smart card 19 may be programmed to categorise different platform 10s. For example, 
platform 10s may be categorised as "fairly trustworthy", "very trustworthy", or "extremely 
25 trustworthy", depending on the type of the platform 10. In this case, the platform 10 type w,ll 
be revealed by the identity information received by the logon smart card 19 from the platform 
10 The logon smart card 19 is programmed to compare the identity Information with pre- 
determined, stored information, where a particular match indicates the category of the 
platform 10 Conveniently, the stored category information forms part of the user profile. 
30 The security policy that the logon smart card 19 adopts with a particular platform 10 

then depends on the category of the platform 10. in one example, the logon smart card 19 
may transmit different user profile information to the platform 10 depending on the platform 
10-s category. For example, with a fairly trustworthy" platform 10. the smart card might only 
pass information relating to crypto cards to the platform 10. to restrict the user to only bang 
35 able to send and receive encrypted emails, or surf, the Internet. Additionally, for fairly 
trustworthy" platform 10s. the user profile information may limit to 'single-session' temporary 
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delegation modes. In contrast, a "very trustworthy" platform 10 may receive user profile 
information that permits multi-session temporary delegation modes and even cash card 
transactions. Finally, an "extremely trusted" platform 10 would receive user^cofile 
information to permit all possible actions including multi-session and cash card tran^^Mis 
5 but also other administrative functions. 

An example of an administrative function, requiring an "extremely trusted" platform 
10, is the ability to create or modify the user profile of a logon smart card 19. When a logon 
smart card 19 verifies that a platform 10 is an "extremely trusted" platform 10, it passes user 
profile information to the platform 10 that includes an option to allow the user to select, from 

10 the secure process, a profile modification option. When the user selects the registration 
process, a special smart card registration process ^wizard' is displayed. This wizard allows 
the user to add a new auxiliary smart card 20, delete an existing auxiliary smart card 20, and 
view the detailed information of each auxiliary smart card 20's ID, such as its public key or 9 
certificate. In the user profile, each registered smart card has a distinguished number and 

15 name given during its registration. 'Wizards' are welt known in the art of computer 
applications, and will not be described in any further detail herein. 

In alternative embodiments, the user profile information may be stored in the trusted 
device 24 or in a remotely located trusted platform 10. Such arrangements would typically 
require different mechanisms for controlling access by the secure process or platform 10 to 

20 the user profile information, but the use of the information once accessed would remain the 
same. 

While the invention has been described with reference to several preferred 
embodiments, it will be appreciated that various modifications can be made to the parts and 
methods that comprise the invention without departing from the spirit and scope thereof. 

25 
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CLAIMS 

(HP Ref: 30980069) 




1. Computing apparatus comprising: 

memory means storing the instructions of a secure process and an authentication 

5 process; 

processing means arranged to control the operation of the computing apparatus 
including. by executing the secure process and the authentication process as required; 

user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user input; and 
10 interface means, for receiving a removable primary token and communicating with the 

token, the token comprising a body supporting: 

a token interface for communicating with the interface means; 

a token processor; and 

token memory storing token data including information for identifying the token, 
1 5 wherein the processing means is arranged to receive the identity information from the 

primary token, authenticate the token using the authentication process and, if the token is 
successfully authenticated, permit a user to interact with the secure process via the user 
interface means, 

and wherein the processing means is arranged to repeatedly authenticate the primary 
20 token and cause the computing platform to suspend interaction between the secure process 
and the user if authentication is not possible as a result of the removal of the primary token. 

2 Computing apparatus according to claim 1 , arranged to generate information representing 
the integrity of the computing apparatus and transmit the integrity information to the primary 
25 token, wherein the token processor is programmed to verify the integrity of the computing 
apparatus including by using the integrity information. 

3. Computing apparatus according to claim 1 or daim 2. wherein the token data includes 
auxiliary token information identifying one or more authorised auxiliary tokens. 

4 Computing apparatus according to claim 3. arranged to read the auxiliary token 
information and. in the event the primary token is replaced by a different token, detect 
whether the different token is an authorised auxiliary token. 

35 5. Computing apparatus according to claim 4. arranged, if the different token is an 
authorised token, to allow the secure process to interact with the authorised token. 
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6. Computing apparatus according to claim 5, wherein the authorised token is a cash token 
and the secure process is arranged to credit or debit the token. 

5 7. Computing apparatus according to claim 5, wherein the authorised token is a crypto token 
programmed to encrypt, decrypt or sign data, and the secure process is arranged to transmit 
data to the crypto token to be encrypted, decrypted or signed and receive encrypted, 
decrypted or signed data from the crypto token. 

10 8. Computing apparatus according to any one of claims 4 to 7, arranged, only if the different 
token is an authorised auxiliary token, to allow the user to interact with the secure process. 

9. Computing apparatus according to any one of claims 4 to 8, further comprising timer 
means programmed with a timeout period, wherein, in the event the different token is an 
15 authorised auxiliary token, the computing apparatus resets the timer and continues operation 
until the timeout period expires, after which time the computing apparatus suspends any 
interactions between the secure process and either or both the user and the authorised 
auxiliary token. 

20 10. Computing apparatus according to claim 9, arranged to recommence said interactions in 
the event the authorised auxiliary token is replaced by the primary token and the computing 
apparatus is able to authenticate the primary token. 

•11. Computing apparatus according to any one of claims 4 to 10, arranged to permit 
25 interaction between the secure process and only one authorised auxiliary token after removal 
of the primary token. 

12. Computing apparatus according to any one of claims 4 to 10, arranged to permit 
interaction between the secure process and more than one authorised auxiliary token after 

30 removal of the primary token. 

13. Computing apparatus according to any one of the preceding claims, wherein the 
processing means comprises a main processing unit and a secure processing unit and the 
memory means comprises main memory and secure memory. 



35 



05-03-99 19:42 44 1 1 7 822 8941 

05/03 '99 19:51 FAX 44 117 922 8941 



P. 24 

HP UK IP SECTION 



R-Z8U Joo-ou* 



11024 



19 



S 



15 



14 Computing apparatus according to claim 13, comprising a trusted device incorporate 
the secure processing unit and the secure memory, wherein the trusted dev.ce « 
programmed to authenticate the primary token repeatedly. 

o 15 Computing apparatus according to ciaim 14. wherein the trusted device is arranged to 
acquire an integrity metric of the computing apparatus, and the primal token is arranged to 
use the integrity metric on at least one occasion to verify the integrity of the comput.ng 

apparatus. 

10 16 Computing apparatus according to any one of the preceding claims, wherein the primary 
token comprises a smart card, and the interface means is configured to receive a smart card. 

17. Computing apparatus according to any one of claims 3 to 16. wherein the auxiliary token 
information is stored In a user profile. 

18 . A method of controlling computing apparatus to authenticate a user, comprising the 

StSPS ' the computing apparatus receiving a primary token of the user, the primary token 
containing information suitable for authenticating the primary token; 

if the token is authentic, permitting the user to interact with one or more secure 
applications that may be executed by the computing platform; 
at intervals, re-authenticating the primary token; and 

if it is not possible to re-authenticate the primary token, suspending the interaction 
between the computing apparatus and the user. 

19 A method according to claim 18, further comprising the steps: 
' . ,he computing apparatus providing integrity metric information to the pnmary token; 

the primary token using the integrity metric information to verify the integnty of the 

computinq apparatus; and 

if the primary token is unable to verify the integrity of the compufng apparatus, 
suspending interaction between the computing apparatus and the user. 

20 A method according to ciaim 18 or Cairn 19. in which the primary token includes 
information relating to one or more authorised auxiliary tokens, wherein, if the user replaces 

35 the primary token with an authorised auxi.iary token, the computing apparatus perm.ts 
interaction between the auxiliary token and the computing apparatus. 
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